1. Field of the Invention
The present invention relates to the field of electronic systems and circuits and, more particularly, to managing configuration of a programmable logic device.
2. Description of the Related Art
Electronic circuit designs can be constructed, simulated, debugged, and translated into electronic hardware using a High Level Modeling System (HLMS). Typically, an HLMS is implemented as a software-based design tool which provides blocks that can be combined to build an electronic circuit. A block refers to a high level software construct that represents a particular circuit function, such as multiplexing, addition, multiplication, or the like. Blocks may have ports that can produce and consume signals, and may be arranged within the HLMS to form a circuit. Communication among the blocks can be represented by wires, or signals, that graphically link the blocks. The design may be simulated within the HLMS once it is constructed. Some HLMS tools can generate a hardware implementation from the block representation of the circuit design. For example, an HLMS can generate the bitstream necessary to program a field programmable gate array (FPGA) or can generate the hardware description language (HDL) files necessary to specify the hardware design.
One example of an HLMS is System Generator for DSP™, available from Xilinx, Inc. of San Jose, Calif. (Xilinx). System Generator for DSP™ is a system level modeling tool that facilitates FPGA hardware design. System Generator for DSP™ provides a wide range of blocks that can be automatically compiled into a design suitable for an FPGA. Among these blocks are high level abstractions that implement complex functions, including digital signal processing as well as communication and control logic. In addition, access to underlying FPGA resources can be provided through low level block abstractions that facilitate the construction of highly efficient FPGA designs.
An electronic design typically is simulated in an HLMS using program logic that models block behavior. It also is possible to incorporate circuit designs, which already have been implemented in hardware, into HLMS simulations. To do so, the computer system hosting the HLMS is connected to the device under test (DUT) via a high bandwidth communication channel, although a low bandwidth communication channel may be used in cases where co-simulation runtime is not of the essence. The DUT typically is a circuit design implemented within a programmable logic device (PLD) such as an FPGA. The PLD is installed on a hardware platform, or circuit board, which is coupled to the host computer system via a communications link. The process of running a simulation involving a hardware platform and a software platform working cooperatively with one another is referred to as hardware co-simulation.
In the course of performing hardware co-simulation, it becomes necessary to reconfigure the PLD at the start of each simulation. One reason for reconfiguring the PLD is that the circuit design being simulated, the DUT, often is dynamic. As such, the circuit design may complete different simulation runs in different states. Further, several of the resources available within devices such as FPGAs lack explicit reset mechanisms. For example, block memories and SRL16s, as are available within the Xilinx Virtex family of FPGAs, lack explicit resets. These sorts of resources must be reprogrammed to a known state prior to the start of a simulation, thereby necessitating the reprogramming of the FPGA.
FPGAs typically are configured, or programmed, using a programmable read-only memory (PROM). The bitstream, also referred to as the configuration image, that is loaded into the FPGA to program the DUT is stored in the PROM. The configuration image is serially loaded into the FPGA upon power-up. This technique can be undesirable for situations in which frequent programming of the PLD is needed, i.e. hardware co-simulation. If the DUT is changed, the PROM itself must be reprogrammed for each different configuration of the DUT. This process can be burdensome in that the PROM must be erased and then reloaded for each different configuration of the FPGA.
It would be beneficial to provide a technique for managing PLD configuration in a manner that addresses the limitations described above.